Summary

PR introduces the SIA v2 (over Butler) FastAPI application. The app utilizes the dax_obscore & daf_butler packages to search for images that match certain query parameters. The API follows the IVOA specification: https://www.ivoa.net/documents/SIA/

A few things to note:

• Current version doesn't yet support querying for multiple different collections, stored in separate Butler repos. This is pending discussion with Gregory & Tim to decide best way to structure obscore configs, repos and the sia app and how the query will interact with these. Potentially we'll have to run a query per butler repo available and combine the results, assuming the result schema is consistent between them..
• Query endpoint is not async. This is because the underlying siav2_query from the obscore package is also not async. If we want to make it async, we probably need some sort of worker system in place.
• Current version is limited to returning VOTable as the response
• Exceptions in query are intercepted and returned as a VOTable error response.
• There is a temporary workaround for Butler to define a default instrument. This should be addressed at some point in daf_butler, after which we can remove the workaround.
• Requirements: The current version has requirements that were generated without hashes, because there isn't a tagged or pip release for dax_obscore with the changes needed.

Design decisions

Current system was designed to support Direct & Remote butler configurations. There is a factory method create_butler which should create the butler based on the configuration passed in. Initially the designed was more abstract, where I defined the notion of a QueryEngine, and DirectButlerEngine, RemoteButlerEngine were implementations, however this felt too abstract and an early optimization for something that may not be needed, i.e. other implementations of siav2_query.

The main configuration other than the butler_type needed is butler_data_collections. This expects a list of ButlerDataCollection objects, which has following parameters, all of which are used to generate the right Butler object. Reason for butler_data_collections being a list, is that we may in the future want to support multiple different Butler repos.

config: The obscore yaml configuration object for the repo 
repository: Path to the repository (May be a URL or a local path)
label: Label for the repo (e.g. "dp02")
defaultinstrument: Default instrument (e.g. "LSSTCam-imSim"")
default:  False Whether this should be the default collection
datalinkurl: If we want to overwrite the datalink_url_fmt attribute in the dax_obscore config.

The query parameters are defined as a dataclass, because it seemed difficult to get a Pydantic model working with list query parameters (related issue: fastapi/fastapi#10556). Also siav2_query has it's own Pydantic model for the SIAv2 Parameters with it's own validation, it seemed better to avoid duplicating the validation.

Prototype notebook

Example notebook demonstrating access via python can be found here:
https://github.com/lsst-sqre/sia/blob/u/stvoutsin/example-notebook/examples/SIAv2_Example.ipynb

How was this tested

A test instance was deployed on data-dev. Process was to modify science-platform app to point to phalanx where sia is enabled, sync only sia and then point the synced sia app to the GH dev branch.

Sample query:
https://data-dev.lsst.cloud/api/sia/query?POS=CIRCLE+55.7467+-32.2862+0.05&time=60550.31803461111+60550.31838182871

Validation was run (using a sample HSC direct butler setup) with the following services and passed with an A++ rating
Euro-vo validation
Paris-vo validation

What hasn't been tested
Apart from the above query, I haven't tested many other parameters, as I'm not really sure about the holdings and what type of queries should return data.

I also haven't fully concluded any concurrent access tests (Ongoing work).